跳到主要内容

参与内核研发

关关难过关关过，在经历了前面的流程之后，我们已经顺利建成了研究 PostgreSQL 的好环境，掌握了为内核带来拓展的能力，并拥有了一张国际社区的通行证，在本篇中，我们将就如何直接参与内核的研发展开讨论。

Git 有关知识的简单回顾​

Git 是 PostgreSQL 管理源代码的方式，回顾 Git 的一些基本概念，可以加强我们对于内核源代码改进流程与基本思路的理解。

  • 状态（status）
    状态代表着软件在当时记录时的源代码情况，从某种意义上它就代表着软件的一个小版本。
    程序员们往往会基于当前的版本，做出一定的改进，形成一个新的小版本（通过 git add 与 git commit 进行记录），进而通过这样的迭代，最终新的大版本来。
  • 分支（branch）
    分支整合着一系列的 commit（提交，实际上就是软件的一个小版本），代表软件的一条发展路线，不同分支的代码提交互不干扰。
    依托这项设计，PostgreSQL 的单一git仓库能够支撑起了五个大版本（五条分支）的同时维护。
  • 标签（tag）
    标签实际上就是一个大的版本号，代表了某条分支在整合了一系列 Commit 后，形成了一个稳定的版本（PostgreSQL 的版本号更新，实际上就是在 git 仓库中增加了一个新的标签）。
  • 补丁（patch）
    补丁代表着从一次 commit 到另外一次 commit（即一个小版本到另外一个小版本）中牵涉到的源代码数据变化。
    PostgreSQL 内核的改进就依靠不同 Developer 发送而来的 Patch 来进行，根据社区的讨论结果决定是否形成一次新的 Commit（即把 Developer 的改进合入 PostgreSQL 中）

PostgreSQL 仓库维护与发布大版本的原理​

这里，我们假定你的 PostgreSQL 源代码经由 git 程序下载下来，在文件夹中，可以执行如下的指令。

git tag

git-tag

可以发现，git 程序返回了许多的 tag，他们代表着不同的 PostgreSQL 版本号，如 PostgreSQL 16.2 对应的 TAG 就是 REL_16_2，PostgreSQL 14.2 对应的 TAG 就是 REL_14_2，我们只需要使用 git checkout 指令，就可以将源代码切换到对应的版本号上面去。

比如，我们可以执行 git checkout REL_14_2 将源代码切换到 14.2 版本来，其它同理。

switch

PostgreSQL 大版本的维护就通过这种方法进行，将仓库切换到不同的标签（一个标签代表一个版本），之后合入对应版本的补丁。

而大版本的发布就是提出新的标签，形成新的分支。

Patch --- PostgreSQL 改进的依据​

Patch 代表了两个小版本之间的文件数据变化，如图所示。

patch

而具体的文件内容，则往往如下所示，记录了版本迭代间牵涉到的文件，以及发生变化的文件内容。

patch_content

而如果我们想要构建自己的 Patch，或者应用别人的 Patch，则需要依托如下的 git 指令。

# 将他人的补丁应用到当前分支的 PostgreSQL 上面来
git am
# 构建自己的 patch
git diff

PostgreSQL 版本演进的时候，就是由不同方面的人们，就某一个 Patch 是否应当合入某个版本展开讨论，最终讨论通过的 Patch，即形成一次 commit，这点我们可以通过 git log 看到。

git-log

PostgreSQL 内核研发的 Reviewer 与 Developer 的区别在于，Reviewer 负责审核 Patch（对版本的迭代给出指导意见），而 Developer 负责提交新的 Patch（尝试提交新的 PostgreSQL 小版本）。

特别感谢​

  • 邱文辉老师